home *** CD-ROM | disk | FTP | other *** search
/ Internet Tools (InfoMagic) / Internet Tools.iso / dos_win / winsock / hacklist / 94-04.Z / 94-04 / 000007_rcq@mailserv-D.ftp.com_Sat Apr 9 07:28:11 1994.msg < prev    next >
Internet Message Format  |  1994-04-30  |  3KB
  1. Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  2.           id AA01251; Sat, 9 Apr 1994 11:29:17 -0400
  3. Received: from ftp.com by ftp.com  ; Sat, 9 Apr 1994 11:29:06 -0400
  4. Received: from mailserv-D.ftp.com by ftp.com  ; Sat, 9 Apr 1994 11:29:06 -0400
  5. Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
  6.     id AA19973; Sat, 9 Apr 94 11:28:11 EDT
  7. Date: Sat, 9 Apr 94 11:28:11 EDT
  8. Message-Id: <9404091528.AA19973@mailserv-D.ftp.com>
  9. To: stcheng@ee.tamu.edu
  10. Subject: Re: setoptsock()
  11. From: rcq@ftp.com  (Bob Quinn)
  12. Reply-To: rcq@ftp.com
  13. Cc: Multiple recipients of list <winsock-hackers@sunsite.unc.edu>
  14. Sender: rcq@mailserv-D.ftp.com
  15. Repository: mailserv-D.ftp.com, [message accepted at Sat Apr  9 11:28:07 1994]
  16. Originating-Client: hurricane.ftp.com
  17. Content-Length: 2244
  18.  
  19. >  setoptsock() allows socket programmers to modify the socket
  20. >  options, like the buffer size for sending and receiving.(using 
  21. >  level= SOL_SOCKET and optname= SO_RCVBUF and SO_SNDBUF)
  22. >  
  23. >  My question is when the  _receiving_  buffer size is bigger than one UDP packet,
  24. >  say 5 times. Will the incoming 5 packets be held in the buffer if
  25. >  the app doesn't read it ? Or no matter how big the buffer size is,
  26. >  it always holds just one UDP packet and discard the subsequence UDP
  27. >  packets if the apps doesn't read it ? What about if the buffer size
  28. >  is 5.3 times of the size of the incoming UDP packets , would the 
  29. >  6th one be stuffed into the remaining buffer size -- .3 of the UDP
  30. >  packet ?
  31.  
  32. The spec is clear: "if the datagram is larger than the buffer
  33. supplied, the buffer is filled with the first part of the
  34. datagram, the excess data is lost, and recv() returns the
  35. error WSAEMSGSIZE."  Where's the ambiguity?  Basically, if
  36. you snooze, you lose :)
  37.  
  38. >  And how about the _sending_ buffer for this case ?
  39.  
  40. I'm not sure how you'd apply the same question to a send(),
  41. but I'll take this opportunity to point out a relevant problem 
  42. with send()/sendto() and UDP datagrams.
  43.  
  44. Our WinSock and stack are incapable of re-assembling incoming
  45. oversized datagrams, but we *can* fragment (out-going) data-
  46. grams.  The reason for this asymmetry is simple: to re-assemble 
  47. incoming datagrams we would need multiple packet buffers, but 
  48. we can use a single packet buffer as we send each outgoing 
  49. fragment.
  50.  
  51. This raises an issue because the WSAData structure only has 
  52. one iMaxUdpDg size; it doesn't differentiate betweeen poten-
  53. tially different sending and receiving datagram sizes.  The 
  54. documentation for send() says it should fail with an error of 
  55. WSAEMSGSIZE if "the datagram is larger than the maximum 
  56. supported by the Windows Sockets implementation" (e.g. the 
  57. iMaxUdpDg value).
  58.  
  59. I admit, we violate the spec in this regard.  But I contend 
  60. that we are justified in doing so because the lack of an 
  61. asymmetrical send/recv iMaxUdpDg represents a deficiency in 
  62. the specification.
  63.  
  64. Comments?
  65. --
  66.  Bob Quinn                                             rcq@ftp.com
  67.  FTP Software, Inc.                                No. Andover, MA